Sheesh, this is a scary PR. 😅 Can't the heavy operation just be done in a controller or at the top of the script and then passed to the component as a value?

It can be worked around, but in my opinion that isn't an ideal DX, as it's just a one-time use variable at that point, and an extra line you need to include for each attribute.

Imagine you have a class-based component with a nested anonymous component, you can call methods on the class based component using $method() closure syntax and pass them directly in to the child: sometimes there isn't a controller. Also with Livewire if you are calling methods on the component with $this->method(), it's not always ideal to pass these in using render() if the data is only required conditionally.

It is a bit scary, but I'm pretty sure it's ok and the changes are actually pretty simple (there are just a lot of compiled snapshot tests that touch this code).

Maybe safer to introduce in 11 if you're hesitant?

Will give it a shot. Thanks.

This pull request breaks passing bound attributes to components if the attribute is not defined as a data attribute of the component.

For example if the component class was:

class Input extends Component
{
public function __construct(
        public string $type = 'text'
    )
}

and the blade view was:

<x-input :name="$getName()" />

Then the name attribute is null when rendering the component attributes.

Hi, what do you mean by "defined as a data attribute"? In the attribute bag?

@danharrin I mean now bound attributes only work if you have defined the attribute in the constructor of the Component class. Otherwise the attribute value is always null. Since the $componentData array does not include those attributes.

How are you accessing the name inside the input? Through the bag or through a variable?

Through the bag.

<input type="{{ $type }}" {{ $attributes }} />

Gotcha, I am going to look at this and submit a PR. I'm not a user of class based components and the test suite doesn't contain any end user component tests

Fix reference: #50479

LOL @danharrin , I was writting an issue about the same report of @dash8x.

Thanks. Unfortunately we'll have to revert this one as it's breaking for too many people: #50482